Recently a number of HDR encoding technologies have been proposed, like e.g. the dual layer method of Dolby (WO2005/1040035). However, the industry is currently still looking for a pragmatic HDR video (/image) encoding technology with fits with (a balance of) all requirements, such as the very important factors like amount of data but also computational complexity (price of ICs), ease of introduction, versatility for the artists to create whatever they like, etc. In particular, a dual layer approach is seen as complex. One would ideally like to be able to design a coding which fits with legacy encoding, such as e.g. DCT-based MPEG HEVC encoding. A problem is that this is somewhat counter-intuitive (how ever can one encode a HDR image, which should by definition be something different from an LDR image, typically having a larger amount of interesting brightness/luminance ranges, in a technology optimized for containing particular LDR images, i.e. to be viewed on displays with peak brightness of about 100 nit and dim surround). These legacy LDR image handling/coding systems were designed and optimized to work with typical LDR imaging scenarios, which are normally well-lit with e.g. a 4:1 in studio illumination ratio (or e.g. 10:1), giving for most of the objects (which can vary in reflectance between say 85% for white and 5% for black) in the view a total contrast ratio of about 68:1 (resp. 170:1). If one looks at relative rendering of the luminances starting from a peak white, a typical early LCD monitor without local dimming would have had something like 100 nit white and 1 nit black which would match with the image contrast ratio, and typically one thought that on average CRT systems which might have been watched also during the day would have something like a 40:1 capability. Having a standard luminance code allocation gamma function of 2.2 in these systems seemed satisfactorily for most scenarios of even higher scene contrast. Although some at the time regarded as acceptable errors were made, such errors of rendering of badly encoded high luminance scene regions (e.g. hard clipping) were also acceptable because LDR displays couldn't render those physically accurate anyway.
However there are scenarios for which there is a desire to improve the rendering, like e.g. an indoors scene in which one can simultaneously see the sunny outdoors, in which case there may be an illumination ratio of 100:1 or even more. In LDR those regions will show up as (soft)clipped (typically already in the encoded image having difficult to discriminate codes around the maximum 255 for those pixels), whereas on a HDR display we would like to show them both bright and colorful. That would give a much more naturalistic and spectacular rendering of such scenes (as if you're really on holiday in Italy), but even scenes where the higher brightness content is only composed of some specular reflections already show a major visual quality improvement. If not already artifacts like clipping or quantization errors look annoying on e.g. a 5000 or 10000 nit display, at least we want to be able to drive such displays with the right kind of image, so that also the rendering will be as beautiful as the display allows.
Classical wisdom was however that to encode additional over-brightness ranges, one would need to have (much) more bits. That could happen either by natively encoding in single larger code words (such as OpenEXR with 16 bits of which a sign bit, 5 bits exponent, and 10 bits mantissa, or Ward's LogLuv encoding, which mathematically rigourously tries to capture the entire world of possible object luminances with high precision), or by using a first layer with standard LDR range codes (e.g. a classical JPEG approximation of the HDR image), and a second layer to improve such pixel luminances to higher brightness (e.g. a boost image to boost each pixel if needed to a higher luminance, i.e. a multiplication of two such 8 bit images being equivalent to a single linear 16 bit code).
A major practical problem to be solved when designing a practical HDR coding technology, in addition to the fact that of course it must be able to handle a huge range of different HDR images, is that hardware manufacturers desire lower amounts of bits per code word (channel) however, and although our below proposed technology can also work with larger bit words, we come with a solution that works nicely under a limitation of 10 bits for at least a luminance (or more precisely a luma) channel. Furthermore, we developed a framework which can do in a dual philosophy both color pixels encoding and color appearance conversion for several rendering scenarios in a functional manner, which means only functions need to be co-encoded instead of for each picture at least a second picture. And by researching and developing this path we discovered what would prima facie not be trivial and disclosed in this patent application that we could really make the system work with good quality by choosing the appropriate function(s) on a luma axis, and even encoding the other two components in a luminance-independent chromaticity plane, which after the development offers further advantages of this coding like free choice of color plane (e.g. for wide gamut), easy calculations inside the codec space itself, etc.